home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc936.txt < prev    next >
Text File  |  1994-08-01  |  10KB  |  229 lines
  1.  
  2.  
  3. Network Working Group                                  Michael J. Karels
  4. Request for Comments: 936                                    UC Berkeley
  5.                                                            February 1985
  6.  
  7.                Another Internet Subnet Addressing Scheme
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.    This RFC suggests a proposed protocol for the ARPA-Internet
  13.    community, and requests discussion and suggestions for improvements.
  14.    Distribution of this memo is unlimited.
  15.  
  16. Introduction
  17.  
  18.    There have been several proposals for schemes to allow the use of a
  19.    single Internet network number to refer to a collection of physical
  20.    networks under common administration which are reachable from the
  21.    rest of the Internet by a common route.  Such schemes allow a
  22.    simplified view of an otherwise complicated topology from hosts and
  23.    gateways outside of this collection.  They allow the complexity of
  24.    the number and  type of these networks, and routing to them, to be
  25.    localized.  Additions and changes in configuration thus cause no
  26.    detectable change, and no interruption of service, due to slow
  27.    propagation of routing and other information outside of the local
  28.    environment.  These schemes also simplify the administration of the
  29.    network, as changes do not require allocation of new network numbers
  30.    for each new cable installed.  The motivation for explicit or
  31.    implicit subnets, several of the alternatives, and descriptions of
  32.    existing implementations of this type have been described in detail
  33.    [1,2].  This proposal discusses an alternative scheme, one that has
  34.    been in use at the University of California, Berkeley since
  35.    April 1984.
  36.  
  37. Subnet Addressing at Berkeley
  38.  
  39.    As in the proposal by Jeff Mogul in RFC-917, the Berkeley subnet
  40.    addressing utilizes encoding of the host part of the Internet
  41.    address.  Hosts and gateways on the local network are able to
  42.    determine the subnet number from each local address, and then route
  43.    local packets based on the subnet number.  Logically, the collection
  44.    of subnets appears to external sites to be a single, homogenous
  45.    network.  Internally, however, each subnet is distinguished from the
  46.    others and from other networks, and internal routing decisions are
  47.    based on the subnet rather than the network number.
  48.  
  49.    The encoding of subnet addresses is similar to that proposed in
  50.    RFC-917.  In decomposing an Internet address into the network and
  51.    host parts, the algorithm is modified if the network is "local", that
  52.    is, if the network is a directly-connected network under local
  53.    administrative control.  (Networks are marked as local or non-local
  54.  
  55.  
  56. Karels                                                          [Page 1]
  57.  
  58.  
  59.  
  60. RFC 936                                                    February 1985
  61. Another Internet Subnet Addressing Scheme
  62.  
  63.  
  64.    at the time each network interface's address is set at boot time.)
  65.    For local addresses, the host part is examined for a subnet number.
  66.    Local addresses may be on the main network, or they may be on a
  67.    subnet.  The high-order bit of the host number is used to distinguish
  68.    between subnets and the main net.  If the high-order bit of the host
  69.    field is set, then the remainder of the high-order byte of the host
  70.    part is taken to be the subnet number.  If the high-order bit is
  71.    clear, then the address is interpreted in the normal fashion.  For
  72.    Class A networks, using 8-bit subnet fields, this allows a network
  73.    with up to 127 subnets, each of 65535 hosts maximum, and a main net
  74.    with 2^23 hosts.  Class B nets may include 127 subnets, each of up to
  75.    255 hosts, and 32767 hosts on the main net.  Class C networks are not
  76.    currently included in this scheme. They might be reasonably be added,
  77.    using four bits of the host part for a subnet desgination and four
  78.    bits for the host, allowing 8 subnets of 15 hosts and 126 hosts on
  79.    the main net.
  80.  
  81.    The current implementation does not use subnet numbers separately
  82.    from the network field, but instead treats the subnet field as an
  83.    extension of the network field.  Functions that previously returned
  84.    the network number from an address now return a network or
  85.    network-subnetwork number.  Conveniently, Class A subnets are
  86.    distinguishable from Class B networks, although each is a 16-bit
  87.    quantity, and Class B subnets are disjoint with Class C network
  88.    numbers.  The net result is that subnets appear to be separate,
  89.    independent networks with their own routing entries within the
  90.    network, but outside of the network, they are invisible.  There is no
  91.    current facility at Berkeley for broadcasting on the logical network;
  92.    broadcasting may be done on each subnet that uses harware capable of
  93.    broadcast.
  94.  
  95. Discussion
  96.  
  97.    There have been several earlier proposals for methods of allowing
  98.    several physical networks to share an Internet network designation,
  99.    and to provide routing within this logical network.  RFC-917 proposes
  100.    a means for encoding the host part of each local address such that
  101.    the hosts, or the gateways connecting them, are able to determine the
  102.    physical network for the host.  The current proposal is most similar
  103.    to that scheme; the differences are discussed in detail below.
  104.  
  105.    Another proposal (RFC-925) involves the use of intelligent gateways
  106.    to perform routing for unmodified hosts, using an Address Resolution
  107.    Protocol (ARP) [2].  This has the advantage of placing all
  108.    modifications in the gateways, but is likely to require additional
  109.    routing protocols and caching mechanisms in the gateways in order to
  110.    avoid excessive broadcasts for address resolution.  A modification of
  111.  
  112.  
  113. Karels                                                          [Page 2]
  114.  
  115.  
  116.  
  117. RFC 936                                                    February 1985
  118. Another Internet Subnet Addressing Scheme
  119.  
  120.  
  121.    this method is to perform encoding of subnets within host addresses
  122.    by convention to simplify the routing in the gateways, without
  123.    modifying host software to recognize these subnet addresses.  These
  124.    techniques were not considered for use at Berkeley, because all
  125.    packet forwarding was being done by multi- homed hosts, all of which
  126.    ran the same software as the singly-homed hosts (4.2BSD Unix).
  127.  
  128.    The most recent proposal, RFC-932 [3], provides subnetting by
  129.    encoding the network part of the Internet address rather than the
  130.    host part.  Ordinary hosts need not know of this convention,
  131.    eliminating the need for modification to host software.  Gateways
  132.    would be able to take advantage of this encoding to compress the
  133.    routing information for the collection of networks into a single
  134.    entry.  Unfortunately, implementation of that scheme would require a
  135.    fairly concerted transition by the gateways of the Internet, or the
  136.    transition period would be likely to overflow the routing tables in
  137.    the existing gateways.  All of the hosts on the larger networks would
  138.    be forced to change addresses from their current Class A or B
  139.    addresses to "B 1/2" addresses.  There are a limited number (4096) of
  140.    blocks of Class C addresses available using this encoding.  The
  141.    number of universities and other organizations having already
  142.    implemented subnets or contemplating their installation argues for a
  143.    more extensible scheme, as well as one that can be implemented more
  144.    quickly.
  145.  
  146.    The current proposal is most similar to that of RFC-917; indeed, the
  147.    two implementations are nearly compatible.  There are two differences
  148.    of significance.  First, the use of a bit to distinguish subnetted
  149.    addresses from non-subnetted addresses allows both smaller subnets
  150.    and a larger (physical or logical) main network.  Half of the host
  151.    addresses within a Class A or B network are reserved for use in
  152.    subnets, the other half are available for the primary net.  This may
  153.    useful when using a hardware medium that is capable of supporting
  154.    large numbers of hosts or for transparent subnetting (e.g. using
  155.    ARP-based bridges).  The corresponding disadvantage is that fewer
  156.    subnets may be supported.  The allocation of bits between the subnet
  157.    number and the host field could be adjusted, but for Class B
  158.    networks, neither is excessively large.  Given the limited address
  159.    space of the current Internet addressing, this is a difficult choice.
  160.  
  161.    The second difference is that the width of the subnet field is fixed
  162.    in advance.  This simplifies the already-too-complicated code to
  163.    interpret Internet addresses, and avoids the bootstrap problem. If
  164.    the subnet field width is to be determined dynamically, some fraction
  165.    of the hosts on a network must be prepared to specify this value, and
  166.    the situation will be unworkable if one of these hosts does not make
  167.    the correct choice or none are accessible when other machines come
  168.  
  169.  
  170. Karels                                                          [Page 3]
  171.  
  172.  
  173.  
  174. RFC 936                                                    February 1985
  175. Another Internet Subnet Addressing Scheme
  176.  
  177.  
  178.    up.  Also, the recovery procedure proposed by RFC-917 seems
  179.    unnecessarily complicated and liable to fail.  Dynamic discovery of
  180.    this value depends on another modification as well, the addition of a
  181.    new ICMP request.  The alternatives are to specify the field size as
  182.    a standard, or to require each implementation to be configurable in
  183.    advance (e.g with a system compilation option or the use of a system
  184.    patch installed when a host is initially installed.  The use of a
  185.    standard field width seems preferable, and an 8-bit field allows the
  186.    most efficient implementations on most architectures.  For Class C
  187.    nets, a 4-bit field seems the only choice for a standard division.
  188.  
  189. References
  190.  
  191.    [1]  J. Mogul, "Internet Subnets", RFC-917, Stanford University,
  192.    October 1984
  193.  
  194.    [2]  J. Postel, "Multi-LAN Address Resolution", RFC-925, USC-ISI,
  195.    October 1984
  196.  
  197.    [3]  D. Clark, "A Subnet Addressing Scheme", RFC-932, MIT-LCS,
  198.    January 1985
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227. Karels                                                          [Page 4]
  228.  
  229.